There are at least three ways to make a new game design: use Xconq commands to "play" a game and then save it, create and text-edit the text files defining a game, or write and run special-purpose programs that create games. A combination of these techniques will likely prove the most useful, since each alone has both strengths and weaknesses. For instance, text editing may seem like a crude approach, but is the only way to produce certain types of scenarios, and text editors have many facilities (such as regular expression replacement) not directly available in Xconq. On the other hand, maintenance of the correct transport/occupant relationships between units is hard to do while editing text, but comes for free when using Xconq itself.
The easiest way to customize Xconq is to build a scenario. A scenario is basically a saved game from which irrelevant details, such as the list of players, has been omitted. Typically this will include tweaking details, removing random irrelevant junk, and generally tuning things.
One way to do this would just be to start a normal game, save it, and then dig through the saved game and edit it, since the saved game is itself a game module. Sometimes this is easy, more likely it will be quite hard and error-prone. A better way is available, in the form of "designer mode".
There are two ways to get into designer mode; one is to start up a game
with the appropriate option (-design under Unix), which makes
every player with a display a designer, the other is to switch on a flag
after the game has started. Being a designer is a property of a side,
so in theory a game could have a designer and several other human
players, or even multiple designers (this might be useful in having
assistants to help with the construction of large scenarios, or just to
have displays open to each side's view of the scenario). AIs
effectively sit out the game while designers are present.
Designer mode enables an additional set of commands on the menu or map control panel, as well as removing some restrictions on the use of normal commands. It also enables more elaborate game saving machinery, so you can save only the parts of a game that you want to make into a scenario.
Modifications to normal commands include the permission to look at and do any command on any unit, including independents and units belonging to other sides. For instance, any unit can be renamed at any time by any designer in the game. The modications include the following:
Some interfaces may also provide additional tool palettes and the like.
If you're not in designer mode, then saving the game will save absolutely everything. In designer mode, the interface should ask you what parts of the game you want to save, and what to name the module.
If you don't save everything, then you should start up another game just
to confirm that you got what you wanted, before shutting down the
Xconq that you're designing with. Sometimes you won't have saved
what you thought you did... It's also a good idea to keep a backup copy
of data, especially the indecipherable area layers; use the nesting
comments #| |# around the old stuff, only delete when you're
sure it's no longer of interest.
Once you've constructed a game, you should bring it to a state where it can be given to other Xconq players. I recommend copying a standard software release strategy. This means documenting how to play the game, documenting how it works internally, removing unused junk and dubious features, simplifying where possible, resolving open issues if possible, documenting them as known problems if not. This gets you to the point of having an "alpha" or "beta" version (the terms are not precise!). These can be given to other people for testing, but should be clearly identified as test versions, because your testers may pass copies along to others without you knowing about it. After some playtesting (see below), edit your game into its final form, call it 1.0 and release it to the world!
After you release your game, you may get some feedback about
unanticipated problems. When you resolve these, and want to make a new
release, be sure to give it a distinct version number. This will be
important to deciding whether subsequent complaints are about your new
release or some older one. If you always put the version number into
the version property of the game-module form, then it will
be displayed to players when they ask for help on the game.
Once the scenario is constructed and saved, you can install it in the
library and otherwise do as you like with it. See the interface
documents for platform-specific installation details; in general, just
copying the files into the lib directory will suffice.
Playtesting is extremely important, even for simple game! You should try as many combinations of startup options as possible - for instance, the combo of two humans and one machine might reveal a peculiarity that is not observed in a two-person game. You can solve many problems by adding more restrictions. Since the scenario is your concept, you are free to make whatever decisions are necessary to realize that concept; if somebody complains, they are free to make their own designs.
Playtesting is the time when you may have to sacrifice realism and favorite theories for playability. Listen to and watch yourself and your testers as the game is played. For instance, you might have included a city out in the boonies, but in the game it never does anybody much good, while still requiring some amount of attention regularly. Lose it.
Game startup can be confusing to players if they all start out with lots of units needing to be told what to do. One solution is to put most units on automatic behaviors that expire in a turn or two, so that novices gradually hear from all the units, while experts can still override right from the outset. Another approach is to make units independent and allow them to be captured early on. Still another approach is to make units come in as reinforcements at preset times and locations. Since players will form their strongest impressions of a game based on its appearance at startup, attention to this will pay off.
While generally safe -- Xconq shouldn't crash while you are designing nor upon starting up your scenario -- you can do silly things, like loading a submarine with battleships as passengers. Xconq won't complain, but it may behave very strangely. For instance, a unit might be able to travel with a transport and leave it, but not be able to get back on again.
One way to test a game is to remove all the scorekeepers and make all the players be AI-controlled. The AI code will then act totally randomly, thus exercising parts of your design that you may not have thought much about. A convenient way to try out various scorekeepers is to put them in variants, then select them upon startup.
Game design often involves subtle questions of balance which will only be revealed by repeated play of the game.
Although as many of the game parameters as possible are checked, there is plenty of room for subtle loopholes. You should think carefully about the consequences of each parameter, being particularly sensitive to degenerate winning strategies. Most common are units that are too powerful, too fast, or are built so quickly that they overwhelm any opposition. Players should always be a little "hungry"; not able to get quite as many units or as much material as they would really like.
Although GDL is a powerful language, you should avoid designing a game that is too complex to be humanly playable. A single game can literally define millions of different parameters, each with a range including 100 to 10,000 distinct values. It is clearly possible to spend many years exploring just a single set of these! For more playable and enjoyable games, either pick a single thing to treat in detail, or else do everything in a simplified way. For instance, if you want elaborate movement and combat rules, avoid or even eliminate materials and associated material handling rules.
Another thing to keep in mind is that the introduction of a new type may have far-reaching consequences. For instance, an additional unit type will need its interactions with all other unit types defined, as well as with terrain and materials, and those new interactions may in turn affect others. One approach is to introduce a new type as a slight modification of an existing type, then to share most of the definitions. Another thing you can do is to put complexity into the variants, so players with a taste for punishment can indulge themselves, while leaving the basic game as more of a fun thing.
Many of the 700-plus game parameters were chosen for their ability to combine in interesting ways, rather than for obvious usefulness. For instance, construction in a city can by default generate an infinite stream of units. But suppose you want to put a limit on the numbers of that type of unit? One way is to define a material that is essential for construction of that type, let the builder have an initial supply, but provide no way to get more of that material. When it runs out, no more units!
Another trick is to motivate an activity by making it a prerequisite to the basic builtin goal of defeating the other player. The age of discovery worked this way. The kings of that time weren't interested in new lands per se; they wanted exploitable possessions, that could be used to get gold, to buy armies big enough to defeat their neighbors. You could describe this situation almost exactly, by making gold a material, obtainable only by the discovery and capture of independent gold mine units, which are thinly scattered over the world and can be found only by careful exploration.
Be inventive! Studying the predefined games should suggest many tricks; the "Tricks and Techniques" section below describes even more. Be sure to document the trick carefully, or the next time you work on the game, you might break it, resulting in unhappy players wondering why their usual strategies don't work anymore.